Attempts to shred graph data, for example, resource description framework (RDF) data into the relational model include a single triple-store relation with three columns, one each for the subject, predicate and object. Therefore, each RDF triple becomes a single tuple, which for a popular dataset like DBpedia results in a relation with 333M tuples, one per RDF triple. The triple-store can deal with dynamic schemas since triples can be inserted without a priori knowledge of RDF data types. However, efficient querying requires specialized techniques and is rather inefficient. Another alternative is a type-oriented approach where one relation is created for each RDF data type. So, for a dataset like DBpedia, one relation is created for people and another relation for companies. Dynamic schemas require schema changes as new RDF types are encountered, and the number of relations can grow quickly considering that DBpedia includes 150K types. A third alternative considers a predicate-oriented approach centered around column-stores where a binary subject-object relation is created for each predicate. So, in DBpedia one relation is created for the born predicate, one for the died predicate, etc. Similar to the type-oriented approach, dynamic schemas are problematic as new predicates result in new relations, and in a dataset like DBpedia these can number in the thousands. Finally, a fourth entity-oriented alternative avoids both the skinny relation of the first approach and the schema changes and thousands of relations required by the latter two.
While alternatives exist, no one alternative is consistently better or consistently outperforms all the other alternatives in every situation. There are cases where even the single-triple store might be useful as a storage medium, while other times column-stores might significantly improve query evaluation. Entity-oriented stores prove advantageous in star-queries, but are less effective in highly selective queries. All of the existing solutions in storing RDF data in relational stores are static in that they fix their RDF representation to one of these alternatives and therefore lose some of the benefits found in the others.